USB 2.0 Transfer, Transaction, and Pipe

Before understanding USB packets and protocols, it is important to distinguish three core concepts that describe different levels of USB communication:

Concept	Level	Description
Transfer	Software / Driver	Complete movement of a data block requested by software
Transaction	Bus / Protocol	Single packet exchange on the USB bus
Pipe	Logical / Abstraction	Communication channel linking host memory to a device endpoint

1. Transfer

A transfer is the complete movement of a block of data requested by software.

Data moves between a USB device endpoint and system memory (RAM)
Managed by the USB driver and host controller hardware
May consist of one or many transactions
The transfer type is determined by the endpoint type: Control, Bulk, Interrupt, or Isochronous

Transfer Types

Transfer Type	Transactions Per Transfer	Error Recovery	Details
Control	2–3 stages (Setup + optional Data + Status)	Yes	See Control Endpoints
Bulk	1 to many (depends on data size)	Yes	Large, non-time-critical data
Interrupt	1 per polling interval	Yes	Small, periodic data
Isochronous	1 per frame/microframe	No	Real-time streaming

Example

Reading a 4 KB block from a USB flash drive:

Software requests 4096 bytes via a Bulk IN transfer
At high-speed, each transaction carries up to 512 bytes
4096 ÷ 512 = 8 transactions to complete 1 transfer

2. Transaction

A transaction is a single exchange of data on the USB bus.

Moves one packet of data (up to the endpoint's wMaxPacketSize)
Uses the Token → Data → Handshake protocol (except isochronous: Token → Data only)
Multiple transactions may be required to complete one transfer
Transactions are atomic — they either complete or fail as a unit

Transaction Flow by Direction

Direction	Step 1 (Token)	Step 2 (Data)	Step 3 (Handshake)
IN	Host sends IN token	Device sends data	Host sends ACK/NAK
OUT	Host sends OUT token	Host sends data	Device sends ACK/NAK/STALL
SETUP	Host sends SETUP token	Host sends 8-byte setup data	Device sends ACK

Short Packets

A transfer is considered complete when one of these conditions is met:

The expected number of bytes has been transferred
A short packet is received — a data packet smaller than wMaxPacketSize
A zero-length packet (ZLP) is received

Note

If the total transfer size is an exact multiple of wMaxPacketSize, the sender must transmit a zero-length packet to signal completion (for bulk and control transfers). Otherwise, the receiver cannot distinguish "transfer complete" from "more data coming."

3. Pipe

A pipe is the logical communication channel between:

A host memory buffer (managed by the USB driver)
A device endpoint (identified by address + direction)

Pipe Types

Pipe Type	Transfer Type	Characteristics
Default Control Pipe	Control	Always exists; uses EP0
Stream Pipe	Bulk, Interrupt, or Isochronous	Unidirectional; no USB-defined data structure
Message Pipe	Control	Structured request/response format

Pipe Properties

A pipe is characterized by:

Endpoint number and direction (from the Endpoint Descriptor)
Transfer type (Control, Bulk, Interrupt, or Isochronous)
Maximum packet size (wMaxPacketSize)
Polling interval (for Interrupt and Isochronous pipes)

Pipe Lifetime

The Default Control Pipe is established as soon as the device is reset (before enumeration)
All other pipes are created when the host selects a configuration via SET_CONFIGURATION
Pipes are destroyed when the device is deconfigured or detached

Relationship Between the Three

┌───────────────────────────────────────────┐
│           Software Request                │
│  "Read 4096 bytes from flash drive"       │
└──────────────────┬────────────────────────┘
                   ▼
┌───────────────────────────────────────────┐
│           Transfer (Bulk IN)              │
│  Composed of multiple transactions        │
│  Managed by host controller driver        │
└──────────────────┬────────────────────────┘
                   ▼
┌───────────────────────────────────────────┐
│           Pipe (Bulk IN Pipe)             │
│  Links host memory ↔ device EP2 IN       │
└──────────────────┬────────────────────────┘
                   ▼
┌───────────────────────────────────────────┐
│     Transaction 1    Transaction 2   ...  │
│  (Token→Data→ACK)  (Token→Data→ACK)      │
│     512 bytes         512 bytes           │
└──────────────────┬────────────────────────┘
                   ▼
┌───────────────────────────────────────────┐
│        USB Device Endpoint Buffer         │
└───────────────────────────────────────────┘

Real-World Example: Reading 4 KB from a Flash Drive

Step	Layer	What Happens
1	Software	Application requests 4096 bytes via file system
2	USB Driver	Driver submits a Bulk IN transfer to the host controller
3	Pipe	Data flows through the Bulk IN pipe (host buffer ↔ EP2 IN)
4	Transaction 1	Host sends IN token → Device sends 512B DATA0 → Host ACKs
5	Transaction 2	Host sends IN token → Device sends 512B DATA1 → Host ACKs
6	Transactions 3–8	Same pattern, alternating DATA0/DATA1
7	Completion	Host controller signals transfer complete; data is in RAM

Host Controller's Role

The host controller is the hardware that converts software transfer requests into bus transactions:

Responsibility	Description
Scheduling	Determines when each transaction occurs within a frame (1 ms) or microframe (125 µs)
Bandwidth allocation	Reserves bandwidth for periodic transfers (Interrupt, Isochronous)
Error handling	Retries failed transactions (up to 3 times for non-isochronous)
DMA	Transfers data directly between device endpoints and host memory
Status reporting	Notifies software of transfer completion or errors